AWS re:Invent2013参加レポート #24 Route53+CloudFront+Route53でオリジンへのリクエストをアレンジする

ども、大瀧です。
re:Inventの期間中、Amazon CloudFrontおよびRoute53(要はEdge Locationを活用するサービス)の開発マネージャの方とディスカッションする中で、おもしろいアーキテクチャが生まれたので共有してみます。

Route53+CloudFront+Route53構成とは

図で示すと、以下のようになります。

一見するとよくあるCloudFrontによるコンテンツデリバリのアーキテクチャですが、CloudFrontのオリジン指定に、Route53で管理するオリジンへのDNSレコードを登録するのがミソです。

ユースケース

このような複雑な構成を組んでなにが嬉しいかというところですが、Route53でオリジン(S3やELB、EC2など)のDNS名をRoute53で管理することで、Route53の持つWeightened Resource RecordやHealth Checkなどの応用機能が活用できます。具体的なユースケースは以下です。

• Weightened Resource Recordを利用することで、エッジロケーションからのアクセスの何割かをオリジンA、残りのアクセスをオリジンBに割り振ることができる。
• Health Checkを利用することで、CloudFrontのエラーレスポンスよりも精度の高いエラーハンドリングが可能になる。

Weightened Resource Recordを利用することで、エッジロケーションからのアクセスの何割かをオリジンA、残りのアクセスをオリジンBに割り振る

たとえば、キャンペーンサイトなどでWebアプリケーションの性能が不足することが予測される場合に、何割かはSorryページをホストするS3バケットへのレコードを返し、Webアプリケーションへのアクセスを規制することができます。

Health Checkを利用することで、CloudFrontのエラーレスポンスよりも精度の高いエラーハンドリングを行う

オリジンにELBへのレコードを設定することで、ELBのDeep Health CheckからRoute53によるSorryページへのフェイルオーバーが実現できます。CloudFrontにも最近カスタムエラー機能が追加されましたが、Deep Health Checkはできません。Route53 + ELBのHealth Checkはこちらのエントリーが詳しいです。

注意点

CloudFrontとRoute53の組み合わせですので、やはりコンテンツキャッシュとDNSキャッシュの性質について十分な理解が不可欠です。今回はエッジロケーションのキャッシュサーバーとオリジンの間にRoute53を挟む形になるので、以下2つのキャッシュを意識する必要があります。

• キャッシュサーバーは通常のページないしSorryページのキャッシュを保持している間は、キャッシュサーバーにアクセスする全てのクライアントに同一のコンテンツを配信します。そのためある程度の分散を期待するのであれば、コンテンツのTTLを短くしたり、キャッシュを無効にするなどの工夫が必要です。
• ここ、ちょっとややこしいところなのですが、クライアントではなくエッジロケーションのキャッシュサーバーがオリジンを問い合わせるDNSレコードをキャッシュします。そのため、1つ目と同様にDNSキャッシュを持つ間キャッシュサーバーは同一オリジンへのアクセスを続け、そのコンテンツをクライアントに返します。これも分散を期待するのであれば、必要に応じてDNSレコードのTTLを調節しましょう。

まとめ

CloudFrontからのオリジンへのアクセスをアレンジするために、Route53の機能を活用するアーキテクチャを紹介しました。re:Inventで発表された新機能の活用に目が行きがちですが、今回のような既存機能を上手に組み合わるバリエーションも増やしていきたいですね。
また、今回の手法はCloudFrontとRoute53のサービス開発のメンバーと話すチャンスから生まれた発想(こちらからサービスなどのフィードバックを伝える中で生まれたアイデア)でした。コアサービスの開発メンバーと交流できるのも、re:Inventというイベントの魅力の一つと感じていただけると嬉しいです。